The views and information expressed in this document represent those of its author(s) who are solely responsible for its content. Borland does not make or give any representation or warranty with respect to such content.
Using Maps with Delphi to Create a New World View

By J. W. Rider

Table of Contents

Overview
Technical Problems

One Moment, Please
A Textbook Solution

Analyze the Problem

What Are We Trying to Do?
What Lets Us Do This?
Can't We Do Them All at Once?
Learn to Talk the Talk

Evaluate the Alternatives

Types of Projections
Orientation Options
Specific Projection Techniques

Design a General Solution

Design Goals
Identify Dependencies Between Components
Geographic Coordinates
Oblique Transformations
Standard Projections
2D Transformations
Digitizing

References
Contact Information

Overview
It might not be every day that you have to present the world in the right way, especially if it's not all that clear what the "right" way is. However, displaying the world in the "right" way is not all that much different from the other kinds of things that a software developer might be asked to do.
In the course of solving all manner of real world problems, a software developer will often be in a position of attempting to reconcile manifold and potentially conflicting requirements. Background information can be extremely technical and esoteric. The developer must balance what is desirable with what is feasible, and make trade-offs between generality of solution and performance. Whenever the developer simply is told to "display everything without any distortion of reality whatever," it is time to fall back on clear and understandable precepts in order to ensure proper program performance according to specification.
Displaying geographic information meaningfully is a straight-forward extension of that exercise, and you can easily adapt Delphi to tackle the problem of displaying such information the "right" way. This problem is no different from any other problem with complex specifications that must also be implemented the "right" way, even when the "right" way is subject to multiple interpretations. The high-level language features of Delphi provide ample flexibility for implementing such complex specifications.
Technical Problems
The visual programming paradigm engrained into Delphi permits developers to put together a front-end very quickly. What makes Delphi more than a pretty prototyping tool is the ability of the language to represent highly technical real-world problems in a manner that aids rapid development.
One Moment, Please . . .
As a group, very technical problems exhibit one or more the following symptoms:

Conflicting requirements
As might be expected, very technical problems tend to be hard to understand, and the interaction of requirements will tend to be not well understood either. There is often a dual requirement to maintain both high accuracy and high performance.

Emphasis on presentation
Very technical problems tend to be composed of many little details, much more than any human could comprehend readily. The technical solution needs to capture the essence of the details and display the information in as understandable a form as possible.

Multiple formats for inputs
Very technical problems tend to employ information from multiple sources and the format in which the information arrives is often beyond the control of the developer. In cartographic applications, a lot of inputs are in the form of various kinds of "maps".

Complex mathematical transformations
Any mathematical transformation becomes complex when you can't look up the formula directly in a standard reference manual. Even if you can find the formula in a reference manual, the transformation is still complex if you cannot immediately identify the formula you need.

Becomes more complex the more it is analyzed
Standard problem-solving techniques break large problems up into smaller ones that are more easily solved. Very technical problems tend to hide a lot of complexity from an initial inspection. Many details will not be uncovered until well into the analysis of the problem.

Multiple interpretations of outputs
The solutions to very technical problems tend to be used by multiple audiences. These audiences will have their own criteria for suitability and quality of outputs. Two users will look at exactly the same display and see entirely different results.

A Textbook Solution
Despite the symptoms, very technical problems can still be solved following the same software development methodology that works for more straightforward problems. The principal complication is that technical problems will tend to be much more iterative and time estimates will be more coarse. However, the developer who can remember to

Analyze the Problem
Evaluate Alternatives
Design a General Solution

will always be in a better position as far as understanding the problem is concerned.
Analyze the Problem
First, you have to get a handle on what it is that you are really trying to do. Then, you need to identify the kinds of features that will let you do it.
What Are We Trying to Do?
Cartography is not merely concerned with drawing maps, but encompasses the whole domain of presenting geographic-related information. Generally, a map projection is the systematic representation of some portion of the surface of a round body onto a flat surface. Historically (well, at least since the 6th century BC), the only "round body" of interest was the Earth and it remains the most important, but other round bodies in the solar system are now also being mapped and studied.
Traditionally, the only flat surface of interest was a piece of paper. Today, more can be done with an interactive, graphic environment than with a piece of paper, but it places more demand on the map projection. For one thing, there is a greater need to go back and forth between flat representation and round representation.
What lets us do this?
If we could use a globe for representing the information, we'd have no particular problem with any particular aspect of the display. Otherwise, we'd like the geographic display to exhibit the same kinds of the following characteristics that we might find on the globe itself:

Every geographic position should be represented.
Squares should appear square.
Equal-sized areas should appear to be the same size.
If two points are close to each other, then they should appear close to each other.
The distance between two points should be proportional to their true distance.
The shortest distance between two points should be a straight line.
The conversion should be simple.

Can't we do them all at once?
Sorry. Unfortunately, no way exists to do all of these together. In fact, there is no particularly good way to satisfy even a large number of the previous characteristics. Every flat map misrepresents the globe in a profound and fundamental way. Furthermore, that way tends to be different for each map.
No matter what you do, distortion is going to exist. You may be able to minimize distortion as well as you can, but it is still going to be there. As long as it is there, you should at least pick the distortion that you want.
Learn to talk the talk
As with any other highly specialized field, cartography has its own specialized vocabulary for dealing with different qualities that you might like to have embedded. When a developer tries to implement these qualities into an application, some attention is needed to ensure that the terminology remains consistent in trying to communicate with other experts in the field.
Some of the vocabulary of the field is not entirely esoteric. Geographic coordinates (locations on the Earth's surface) are expressed in terms of latitude and longitude, both of which are expressed as angles from a base position. Latitude measures degrees north or south from the equator. Longitude measures degrees east and west from the prime meridian. Lines of equal latitude are called parallels, and lines of equal longitude are called meridians.
After that, the field vernacular becomes more obscure. A map projection

is conformal (or "orthomorphic") if shapes are preserved. Squares will still be square. Circles will be circular.
is equal area (or "equivalent" ) if sizes are preserved. Squares might not appear as square. They might be parallelograms instead.
is equidistant if distances remain proportional. In general, map projections are only equidistant in particular directions.
has true direction if angles between lines are preserved.
has perspective if the display follows straight line projections from a central position. Some of the azimuthal displays tend to be perspective, and if you are trying to consolidate imagery from orbiting satellite, the imagery will always be in perspective as well.
has straight rhumbs if the angles between meridians are preserved. In navigation, a rhumb line (also known as a loxodrome) is along a course with a constant heading. Only the Mercator projection provides this feature.
has straight great circles if the shortest distance between any two points is a straight line. Only the Gnomonic projection has this feature.

Evaluate the Alternatives
Over the years, cartography has developed a number of special-purpose projections. The utility of these projections doesn't change when the information is displayed on a computer.
Types of Projections
Azimuthal (Zenithal)
Azimuthal (Zenithal) attempts to represent the surface of the globe on to a flat plane tangent at some location, which will be in the center of the display. Radial lines from the center are always great circles.
In the standard orientation, the center of the display is the north or south pole. Meridians are straight lines radiating from the center. Parallels are concentric circles.
During implementation, use polar coordinate to rectangular coordinate conversions for azimuthal transforms:

You need to pick a base Longitude, and the prime meridian is a convenient choice.
Use co-Latitude instead of Latitude. (The co-Latitude is the complement of the Latitude and is computed by simply subtracting the Latitude from 90 degrees.)
Use radians instead of degrees.
Use different functions of co-Latitude only to effect different projection techniques.

Several azimuthal projections can be described in relatively simple geometric terms:

Gnomonic (projected from center of earth), all straight lines are great circles
Stereographic (projected from opposite point), conformal
Orthographic (projected from infinity)

Conical
The azimuthal projection provides a simple transformation between a globe and a two dimensional plane. The principal of the conic projection is to project the globe onto a cone, and then apply another transformation that effectively cuts the cone along a seam and lays it flat. The net effect is that the conical display resembles a portion of the azimuthal display.
In the standard orientation, the apex of the cone is placed over a pole, and the cone is tangent to a single parallel or secant through two parallels. As in the standard azimuthal, meridians are straight lines. However, the meridians don't intersect at the center of the display. Similarly, parallels are circular, but not complete circles.
During implementation, a slight modification of the polar coordinate conversion can be used. Longitude must be scaled slightly to account for the v-shaped cutout that appears when the cone is laid flat.
Cylindrical
In addition to projecting onto a plane, or onto a cone which is then laid flat, another effect can be achieved by enveloping the globe in a cylinder, projecting the globe onto the cylinder, cutting the cylinder along an edge and laying it flat.
In the standard orientation, the cylinder is tangent to the equator. Both meridians and parallels are represented as straight lines.
During implementation, latitude and longitude is converted readily to the Y and X respectively of the resultant display. Some basic observations:

X is always in direct proportion to Longitude.
Y is a function of Latitude only. (Different functions are used to effect different techniques.)

Other ("PseudoCylindrical")
Other projections are possible and the categories are called different names by different authors. While many techniques are possible, the most favored techniques display the following common attribute:
In the standard orientation, parallels are straight lines and meridians are curved. The family of curves formed by the meridians depend upon the underlying functions.
During implementation, both X and Y have to be computed from the latitude and longitude.

Y is a function of Latitude only.
X is a function of both Latitude and Longitude.

In both cases, different functions will be used to effect different techniques.
Orientation options
All projections have a normal (or "standard" ) orientation. Azimuthal and conical projection are normally oriented over a pole and thus have a polar orientation. Cylindrical and pseudocylindrical orientations are wrapped around the equator and thus are deemed to have an equatorial orientation. If the orientation is inclined at a right angle (say, placing an orthographic projection tangent to a point on the equator, or wrapping a Mercator projection around some meridian), then the projection is transverse.
If the orientation is neither polar or equatorial, then it is called oblique.
The pseudocylindrical projections can also have an additional variation by making multiple cuts into the surface of the globe (usually along selected meridians) . The effect has occasionally been described as trying to flatten an orange peel. When displayed in this fashion, the projection is interrupted.
Specific Projection Techniques
Even before automated techniques, cartographers would mix and match different properties and conditions to yield numerous named projections. The literature is rich with individuals who have put their names to some projection or another; sometimes, more than one. To conserve space, only a handful of projections are identified below. This should be sufficient to provide a feeling of the numbers and diversity of projections which may need to be incorporated into a Delphi application.

Albers Conic Equal Area (dated from early 19th century)
As the name implies, a conical projection with the latitude spacing adjusted so that areas on the globe are in proportion. Well-suited for large countries or other areas that are maily east-west in extent.

Elliptical Equal Area ("Mollweide")
A pseudo-cylindrical projection where each meridian follows the arc of an ellipse.

Equidistant (Simple) Azimuthal
Not every projection has an individual's name attached to it, but some are sufficiently important that they can be described by their properties alone. The "simple" projections have the added advantage of not depending upon some complex expression to convert between geographic coordinates and image coordinates.

Equidistant (Simple) Conic
Known from the second century. Despite its simplicity, it is a rarely used projection.

Equidistant (Simple) Cylindrical ("Plate Carre")
The simplest conversion of latitude and longitude to cartesian coordinates that there is. Not used often in traditional cartography because no special features are preserved.

Gnomonic
Azimuthal projection from the perspective of the center of the earth. A unique feature is that all great circles are represented by straight lines; not just the great circles that go through the mid-point of the projection. Known from the sixth century, B.C.

Lambert Conformal Conic. (from late 18th century)
Possibly the most widely use projection for displaying the contiguous United States.

Lambert Equal Area Azimuthal. (from late 18th century)

Mercator Conformal Cylindrical
A projection well-known even to non-specialists since its introduction in late 16th century. A conformal (shape-preserving), cylindrical projection, but definitely not equivalent (area-preserving). One unique feature of the "standard" Mercator is that rhumb lines (lines that cut all meridians at the same angle) are straight. Widely used for maps showing the whole world.

Transverse Mercator
The standard Mercator is a standard cylindrical projection, (i.e., the cylinder is wrapped around the Earth at the equator), but neither of the Earth's poles can be represented. The transverse Mercator (introduced late 18th century) tilts the cylinder so that it wraps around the Earth along some meridian. Both of the poles are represented this way.

Oblique Mercator
If the basic Mercator projection is used, but the cylinder is wrapped along something other than the equator or a meridian, the projection is "oblique". In an atlas, this projection might be used to represent some region that is much longer than it is wide. For example, when both North and South American continents are displayed together, this projection has some advantages. Developed in early twentieth century.

Orthographic
The transverse orientation of this azimuthal projection is often used for perspective views of the Earth, moon and other planets, since the resulting image of the body as it would appear if taken with a camera at great distance. The oblique orientation is often used to provide a "where in the world" perspective of a region that described in more detail through another projection with smaller scale.

Sinusoid Equal Area. (also called "Sanson-Flamsteed" but first used by others in the late 16th century)
Usually interrupted.

Stereographic
A conformal, azimuthal projection from the second century B.C.

Design a General Solution
The next step in the solution of technical problems usually involves taking a step back and seeing how you might put everything in as general a fashion as possible.
Design goals
From the beginning the basic precept has been to come up with a way of taking a geographic coordinate and figuring out where to plot that point on some flat surface. During the course of evaluating alternatives, it should have become obvious that there were a number of different paths to take, and which to take would depend upon other kinds of desired features. We can select from a variety of components, and by mixing up the underlying functions, we can achieve a number of specific results.
Identify dependencies between components
By partitioning the whole conversion process into small pieces, the entire projection can be described in a straightforward sequence of steps. The diagram below shows the steps required to convert a geographic coordinate into a pixel position for display or data-base key for retrieval. Following the flow down indicates one aspect, but the implementation will be incomplete if the reverse direction is not developed as well.

Geographic Coordinates
The underlying transformations will work most efficiently if the geographic coordinates are expressed in radians. This is not how geographic information is usually known. At best, the information will be presented in degrees and fractional degrees. Often, the information will be presented in degree/minute/second (DMS) format.

Const DegRadFactor = 0.017453292519943;
Const RadDegFactor = 57.2957795131;

Function DmsToDegrees( D,M:integer; S:real): real;
begin
Result:= D + (M + S/60.0)/60.0;
end;

Function DegreesToRadians( Degrees:real): real;
begin
Result := Degrees*DegRadFactor;
end;

Function RadiansToDegrees( Radians:real): real;
begin
Result := Radians*RadDegFactor;
end;

Function DegreesToDMS( Degrees:real; var D,M: integer): real;
begin
Degrees := -Degrees; { handle sign elsewhere }
D := Int(Degrees);
M := Int(60.0*(Degrees-D));
Result := Degrees - D - M/60.0; { return seconds as function result }
end;

Oblique Transformations
While the decomposition of the geographic conversion process will simplify most aspects of the conversion, oblique transformations remain a stumbling block. The oblique transformation requires solving a problem in spherical trigonometry, and there is no easy way to avoid this.

Type TGeoCoord = record x,y: real; end;

{ Computing these ahead of time prevents their recomputation for
every converted coordinate }

Const sinOblPtLat: real = 0.0;
Const cosOblPtLat: real = 1.0;
Const sinOblPtLong: real = 0.0;
Const cosOblPtLong: real = 1.0;

Procedure SetObliquePt(ObliquePt: TGeoCoord);
begin
sinOblPtLat := sin(ObliquePt.Y);
cosOblPtLat := cos(ObliquePt.Y);
sinOblPtLong := sin(ObliquePt.X);
cosOblPtLong := cos(ObliquePt.X);
end;

Function GeoToOblique( Pt: TGeoCoord): TGeoCoord;
var sinLat, cosLat, sinLong, cosLong: real;
sinResultLat: real;
begin
sinLat := sin(Pt.Y); cosLat := cos(Pt.Y);
sinLong := sin(Pt.X); cosLong := cos(Pt.X);

{ apply "law of cosines" for spherical triangles }
sinResultLat := sinLat*sinOblPtLat
+ cosLat*cosOblPtLat*(cosLong*cosOblPtLong+sinLong*sinOblPtLong);

{ apply "law of sines" for spherical triangles }
Result.X := arcSin(
(sinLong*cosOblPtLong+cosLong*sinOblPtLong)*cosLat
/sqrt(1-sqr(sinResultLat)));
Result.Y := arcSin(sinResultLat);
{ NOTE: "arcSin" is not a standard Delphi function }
end;

Standard Projections
At this point, one of the standard mapping projections can be applied.

Const POLELAT = 1.5707963; { latitude of north pole in radians }

Type realfunc1: function (real):real;
Type realfunc2: function (real,real):real;

{ This is an example of a function of type realfunc1 }
{ It would be used for the "simple" projections }
Function Simple1(x:real): real;
begin
result:=x;
end;

{ Other selected realfunc1 transforms: }

Function Tan1(x:real):real; { for Gnomonic }
begin
result:=sin(x)/cos(x);
end;

Function HalfTan1(x:real):real; { for Stereographic }
begin
result:=2*Tan1(x/2);
end;

Function Sine1(x:real):real; {for Orthographic and Cylindrical Equivalent}
begin
result:=sin(x);
end;

Function HalfSine1(x:real):real; { for Azimuthal Equivalent }
begin
result:=2*sin(x/2);
end;

Function GD1(x:real):real; { for Mercator Conformal }
begin
result:=ln(1-Tan1(x));
end;

{ An example of a realfunc2 }
Function LongCosLat2(Long,Lat:real):real; { for sinusoid equivalent }
begin
Result:= Long*cos(Lat);
end;
{The corresponding realfunc1 for the sinusoid equivalent would be
Simple1}

function StandardToAzimuthal(
Standard:TGeoCoord; CoLatFunc:realfunc1):TGeoCoord;
var clf_result:real;
begin
{ The CoLatitude function expects an argument that
is the complement of the Latitude, so it is computed
as necessary }
clf_result:=CoLatFunc(POLELAT-Standard.Y);
Result.X := clf_result*sin(Standard.X);
Result.Y := clf_result*cos(Standard.X);
end;

function StandardToCylindrical(
Standard:TGeoCoord; LatFunc:realfunc1):TGeoCoord;
begin
Result.X := Standard.X;
Result.Y := LatFunc(Standard.Y);
end;

function StandardToPseudoCylindrical(
Standard:TGeoCoord;
LatFunc:realFunc1;
LongFunc:realFunc2):TGeoCoord;
begin
Result.Y := LatFunc(Standard.Y);
Result.X := LongFunc(Standard.X, Standard.Y);
end;

2D transformations
Handling translation and rotation of two-dimensional Cartesian coordinate systems is something that programmers with any math experience have usually needed to accomplish.

const CosThX: real = 1;
const SinThX: real = 0;
const CosThY: real = 1;
const SinThY: real = 0;

const GeoCenter: TGeoCoord = ( x:0, y:0 );

function ImageToNormal( Image: TGeoCoord): TGeoCoord;
begin
Result.X := CosTh*Image.X + SinTh*Image.Y + GeoCenter.X;
Result.Y:= -SinTh*Image.X + CosTh*Image.Y + GeoCenter.Y;
end;

Digitizing
This could turn out to be the easiest conversion to accomplish or one of the most difficult. The other conversions are based upon mathematical descriptions of the involved geometry. Determining the pixel location is complicated mainly by the inversion of the graph coordinate system. Otherwise, scaling and rounding are all that is required. Determining the data-base key for extracting information to be displayed from some other file can be more involved.
References

Almost any good atlas of the world will have ample explanation of the different kinds of world projections and, indubitably, several examples.
For a more thorough explanation of the projections, see Snyder, John P., Map Projections: a Working Manual, Geological Survey Professional Paper 1395 (Washington: USGPO, 1987).
For a general introduction to the mathematics and computer implementations of several projections, see Pearson II, Frederick, Map Projections: Theory and Applications ( Boca Raton, Florida: CRC Press, Inc., 1990).
For a contemporary and graphic assessment of the use of a variety of world projections, see Wood, Denis, "The Power of Maps," Scientific American (May 1993, Vol 268, No 5), pages 88-93.

Contact Information
J. W. Rider can be reached on COMPUSERVE at ID number 70007,4652.
Delphi Technical Library
Borland's Technical Library

Copyright © 1996 Borland International, Inc.
Last Modified: March 10, 1996